home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / The World of Computer Software.iso / risk1420.zip / RISK1420.TXT < prev   
Text File  |  1993-01-03  |  28KB  |  547 lines

  1. ·    Subject: RISKS DIGEST 14.20
  2.  
  3. RISKS-LIST: RISKS-FORUM Digest  Thurs 31 December 1992  Volume 14 : Issue 20
  4.  
  5.         FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
  6.    ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
  7.  
  8.   Contents:  [***** HAPPY NEW YEAR!!! *****]
  9. Another Jail Computer Glitch (PGN)
  10. Antiviral technology target of legal action
  11. Dutch chemical plant explodes due to typing error (Ralph Moonen)
  12. 911 in Massachussetts (Barry Shein)
  13. What about "little brother?" (Brian Seborg)
  14. Re: Electronic democracy (Barbara Simons)
  15. Re: Programming errors affect state lottery (Charles D. Ellis)
  16. Re: Bundestag speechless (Boris Hemkemeier, Markus U. Mock, Daniel Burstein)
  17. Latest (?) credit card scams (Jerry Leichter)
  18. Risks of satellite-controlled anti-theft devices (Jim Griffith)
  19. OECD Security Guidelines (Marc Rotenberg)
  20.  
  21.  The RISKS Forum is moderated.  Contributions should be relevant, sound, in
  22.  good taste, objective, coherent, concise, and nonrepetitious.  Diversity is
  23.  welcome.  CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive
  24.  "Subject:" line.  Others may be ignored!  Contributions will not be ACKed.
  25.  The load is too great.  **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
  26.  especially .UUCP folks.  REQUESTS please to RISKS-Request@CSL.SRI.COM.
  27.  
  28.  Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
  29.  CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 14, j always TWO digits).  Vol i
  30.  summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
  31.  The COLON in "CD RISKS:" is essential.  "CRVAX.SRI.COM" = "128.18.10.1".
  32.  <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
  33.  
  34.  For information regarding delivery of RISKS by FAX, phone 310-455-9300
  35.  (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com).
  36.  
  37.  ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
  38.  Relevant contributions may appear in the RISKS section of regular issues
  39.  of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
  40.  
  41. ----------------------------------------------------------------------
  42.  
  43. Date: Wed, 30 Dec 92 11:16:35 PST
  44. From: "Peter G. Neumann" <neumann@csl.sri.com>
  45. Subject: Another Jail Computer Glitch
  46.  
  47. Around 7pm on 27 December 1992, the new San Joaquin (California) County Jail
  48. computer system automagically unlocked all of the cell doors in a high-risk
  49. area, with a highly audible series of loud clicks, releasing about 120
  50. potentially dangerous inmates who were being held in an "administrative
  51. segregation pod."  Fortunately, the pod was itself isolated by other doors
  52. that remained locked.  The glitch was attributed to a spurious signal from the
  53. "incoder card" whose responsibilities include opening those doors in
  54. emergencies.  [Source: San Francisco Chronicle, 30 Dec 1992, p.A14, article by
  55. Peter Fimrite]
  56.  
  57. Fimrite's article also noted other California cell-door problems.  Less than a
  58. year after the supposedly escape-proof Pelican Bay State Prison near Crescent
  59. City CA opened, inmates learned how to pop open the pneumatic cell doors at
  60. will.  A similar system in the Santa Rita Jail in Alameda County was also
  61. found to be pickable.  [If it had required breaking DES, that situation might
  62. have been DES-pickable!]
  63.  
  64. For those of you new to RISKS (or in case Fimrite or his Chron colleages see
  65. this in RISKS), our archives include the following computer-related cases.
  66. (Rather than grep-ing through the back issues, I give references to back
  67. issues of the ACM SIGSOFT Software Engineering Notes, containing material
  68. derived from the earlier issues of RISKS.  S 10 1 is dated Jan 84, S 12 4 is
  69. Oct 87, S 13 4 is Oct 88, S 17 1 is Jan 92.)
  70.  
  71.   ..... Earlier prison problems
  72.   Santa Clara prison data system (inmate altered release date) (S 10 1)
  73.   Drug kingpin escapes LA County prison via bogus release message (S 12 4)
  74.   Convicted forger released from Tucson jail via bogus fax (S 17 1)
  75.   Seven Santa Fe inmates escaped; prison control computer blamed (S 12 4)
  76.   Oregon prisoner escaped; frequent-false-alarm alarm ignored (S 12 4)
  77.   New Dutch computer system frees criminals, arrests innocent; old system
  78.     eliminated, and no backup possible! (S 12 4)
  79.   New El Dorado jail cell doors won't lock -- computer controlled (S 13 4)
  80.  
  81. ------------------------------
  82.  
  83. Date: Thu, 31 Dec 92 11:31:38 PST
  84. From: Peter G. Neumann <neumann@csl.sri.com>
  85. Subject: Antiviral technology target of legal action
  86.  
  87. The Washington Post has an article by John Burgess (at least some of which
  88. appears in today's San Francisco Chronicle) discussing a federal judge's order
  89. to McAfee Associates of Santa Clara CA, to stop distributing their Pro-Scan
  90. Version 2.31 and ViruCide Version 2.33 and derivative products.  Imageline
  91. Inc. of Richmond VA (maker of PicturePak and ValuePak) has sued McAfee
  92. Associates for libel, fraud, and other misdeeds, because those antiviral
  93. products mistakenly identify Imageline products as containing viruses.  Stay
  94. tuned for further details.
  95.  
  96. ------------------------------
  97.  
  98. Date: Wed, 23 Dec 92 09:26 GMT
  99. From: rmoonen@ihlpl.att.com
  100. Subject: Dutch chemical plant explodes due to typing error
  101.  
  102. In the first half of this year the chemical factory Cindu exploded causing
  103. several deaths and a chaos. It was confirmed yesterday that a simple typing
  104. error led to this tragic accident. Apparently the computerised chemical
  105. processing installation was fed with data in which a comma was placed at a
  106. wrong digit, causing the wrong amount of chemicals to be mixed in the
  107. installation. This led to an enormous explosion and the closure of the
  108. factory.
  109.  
  110. The Dutch news said that the responsible person has been found and he
  111. will be charged with negligible conduct causing death.
  112.  
  113. BTW: This year has been disaster-year for the Netherlands. We have had 2
  114. serious plane crashes: the well-known El al 747 that crashed into two
  115. apartment buildings, the DC10 with 300 Dutchmen aboard that crashed in Faro
  116. this week. We had the Cindu explosion, an earthquake (yes, in Holland) 2 major
  117. train-accidents, and quite a few lesser accidents. I hope the next year will
  118. have some mercy on us :-)
  119.                                      --Ralph Moonen
  120.  
  121. ------------------------------
  122.  
  123. Date: Wed, 30 Dec 1992 01:24:42 -0500
  124. From: bzs@world.std.com (Barry Shein)
  125. Subject: 911 in Massachussetts
  126.  
  127. I assume you have already been inundated with the issue of the woman
  128. who was murdered by (her ex-husband I believe) here in Boston. It
  129. seems she dialed 911 when she heard him at the door but unfortunately
  130. her exchange was a Brookline exchange (a neighboring township a few
  131. blocks away, not politically part of Boston), so the 911 call went to
  132. the Brookline Police. On hearing her address the Brookline police
  133. informed her she needed to call the Boston Police.
  134.  
  135. I am not certain of the exact details of what ensued (I'm not sure
  136. anyone outside of the Police departments is certain yet), the
  137. Brookline police claim the delay would not have made any difference in
  138. the outcome (her murder), but of course that's a fairly convenient
  139. position for them to take.
  140.  
  141. This has been a front-page story in the Boston Globe these last few days.
  142. Makes one want to pick up their phone and dial 911 and see exactly who you get
  143. and ask whether they would actually come should you need them.
  144.  
  145.         -Barry Shein
  146.  
  147. Software Tool & Die   bzs@world.std.com  uunet!world!bzs  617-739-0202
  148.  
  149. ------------------------------
  150.  
  151. Date: Wed, 23 Dec 92 12:28:17 EST
  152. From: Brian Seborg <seborg@first.org>
  153. Subject: What about "little brother?"
  154.  
  155. In the past we have tried to control information collected by "Big Brother" or
  156. the Federal Government.  I believe that this has for the most part been
  157. accomplished.  What has not been done, and what seriously needs to be
  158. addressed is the collection and dissemination of information by numerous
  159. "Little Brothers."  Specifically, additional guidance is needed to protect
  160. information maintained by credit reporting agencies, State Government
  161. agencies, retail stores, and other entities which routinely collect
  162. information that can be linked to an individual by name or other unique
  163. identifier.
  164.  
  165. Since I teach a computer security class at a local college, the issue of
  166. privacy seems even more important once you know how many ways the information
  167. can be compromised.  After a lecture on privacy one of my students mentioned
  168. that he worked with some private investigators, and he mentioned that they
  169. routinely had access to all kinds of information on people, and that agencies
  170. such as the state department of motor vehicles routinely sold access to their
  171. records to just about anyone.
  172.  
  173. To illustrate the problem I asked the student to initiate an inquiry and to
  174. see what he could find out with only my name as information.  The next class
  175. he brought me the results of his spending about 30 minutes at a computer
  176. terminal.  Here is a partial list of what he provided me in printed form: my
  177. current address, the addresses of all my previous residences, a list of all of
  178. the automobiles I have ever owned, my social security number, my drivers
  179. license number, a list of all of the credit cards I have ever owned including
  180. cancelled cards, their credit limits, the credit card numbers, and the current
  181. balance, the name and address of my employer, my father and brother's name and
  182. address, the name of my wife, the name address and phone numbers of all of my
  183. neighbors, their date of residence, and the type of home they had, my criminal
  184. record (blank) along with any pending cases, my traffic record (not blank
  185. unfortunately!  :-)), my race, my income, the amount of my mortgage, my credit
  186. rating, etc.  I imagine that most people have no idea that such information
  187. about them is so easily accessible.  Imagine the potential for coming up with
  188. a detailed profile of a person once you begin associating individuals to the
  189. groceries they buy if the current trend of using check cashing cards or
  190. bank-cards to pay for groceries really catches on!  For example, could you
  191. imagine who might want to have access to lists of customers which bought
  192. specific products?  Giant supermarkets (a large chain in our area) already has
  193.  
  194. the computer printing out coupons based on the purchases you have made, what
  195. would they do with this information if they could associate you with the
  196. groceries you bought?  One could imagine the following phone call after
  197. purchasing a bladder control product: "Yes, Mr. Seborg, this is the office of
  198. Dr. Nosey, Urologist, we are offering five dollars off your initial
  199. consultation, when can we schedule you for your first appointment?"  Or worse,
  200. you could have someone inferring some personal profile based on your patterns
  201. of consumption.  Far fetched, maybe, but I bet you may think before you use
  202. that bank card, or check cashing card next time at the grocery store, eh?
  203.  
  204. Brian Seborg, VDS Advanced Research Group  seborg@csrc.ncsl.nist.gov
  205.  
  206. ------------------------------
  207.  
  208. Date: Wed, 23 Dec 92 12:36:33 PST
  209. From: Barbara Simons <simons@almaden.ibm.com>
  210. Subject: Re: Electronic democracy (Agre, RISKS-14.19)
  211.  
  212. >Now, some people argue that electronic open government will level the
  213. >playing field by giving The People access to the same information as special
  214. >interests.  But maybe it doesn't work that way. ....
  215.  
  216. Agre then goes on to ask if we should welcome or oppose electronic "open
  217. government" if our primary interest is in strengthening democracy.
  218.  
  219. I agree that there are many pitfalls related to the question of electronic
  220. democracy as it is usually described.  The one that I find most disturbing is
  221. the question of access.  Users of the net tend to be white males from a
  222. certain age group and socio-economic class.  There are very few
  223. representatives of the impoverished underclass on the net, and women are very
  224. much underrepresented.  Also underrepresented are old people and very young
  225. people.  If we were to increase access to government for users of the net, we
  226. would be increasing access for a relatively prosperous, well educated, and
  227. successful group, at the expense of much of the rest of the country.  This is
  228. not a healthy situation for a democracy.
  229.  
  230. There is a serious risk of disenfranchisement contained within the standard
  231. description of electronic democracy.  While this may not be the sort of risk
  232. usually discussed in this forum, it is nonetheless significant, and it is
  233. possible only because of computers.
  234.  
  235. Barbara Simons
  236.  
  237. ------------------------------
  238.  
  239. Date: Fri, 18 Dec 1992 19:19:28 GMT
  240. From: cde@aplexus.jhuapl.edu (Charles D. Ellis)
  241. Subject: Re: Programming errors affect state lottery (Seecof, RISKS-14.18)
  242.  
  243. GTECH, the company which got the mysteriously beneficial contract change
  244. indemnifying them from operational goofs is in the news big time here in
  245. Maryland.
  246.  
  247. It seems that allofasudden/outoftheblue they were awarded a contract for Keno
  248. which was a total surprise to all, including the state legislature. The
  249. no-bid award was justified due to a "fiscal emergency".
  250.  
  251. They must have one hell of a contracts department!
  252.  
  253. Charlie Ellis   cde@aplexus.jhuapl.edu
  254.  
  255. ------------------------------
  256.  
  257. Date: Sun, 27 Dec 1992 20:01:46 +0100
  258. From: Boris Hemkemeier <boris@math30.mathematik.uni-bielefeld.de>
  259. Subject: Re: Bundestag speechless (Weber-Wulff, RISKS-14.19)
  260.  
  261. The earlier report is only the half story.  The president of the German
  262. Bundestag has a new priority button that switches off all microphones except
  263. his own.  After resuming the debates in the new building, Johnny Klein put a
  264. heavy book on the button and didn't notice the effect.  Security personal
  265. prevented technicians from entering the Bundestag.  Then the parliament
  266. decided to move back to his old building, which incidentally is controlled by
  267. the same (working!) computer.  (See the German newspaper, Die Zeit, "Johnny
  268. griff daneben", for details.)
  269.                                                    Boris Hemkemeier
  270. boris@mathematik.uni-bielefeld.de.
  271.                                              [Eine KLEINe NICHTmusik!  PGN]
  272.  
  273. ------------------------------
  274.  
  275. Date: Wed, 23 Dec 92 15:39:43 MET
  276. From: "Markus U. Mock" <mock@ira.uka.de>
  277. Subject: Re: ... Bundestag speechless (Weber-Wulff, RISKS-14.19)
  278.  
  279. [...] If this event shows the risks of complex technical systems, the light
  280. was actually cast on the un-informed 'user' community and the lack of
  281. information transfer to those who will use the systems.  [...]
  282.  
  283. Markus U. Mock, University of Karlsruhe, Dept. of Computer Science
  284. @DATAPHONE@@CITY@@FIRST@@USER@mock@ira.uka.de ukj6@dkauni2.bitnet
  285.  
  286. ------------------------------
  287.  
  288. Date: Wed, 23 Dec 92 04:15 GMT
  289. From: Daniel Burstein <0001964967@mcimail.com>
  290. Subject: Bundestag sound problems (RISKS 14.19)
  291.  
  292. Hmm, seems I recall seeing this problem demonstrated at length in the mid
  293. 1960's.  Didn't Don Adams and Barbara Feldon (and Edward Platt) repeatedly run
  294. into problems of this sort when using the "Cone of Silence" over at
  295. "Control"?
  296.  
  297. Since the show was a continuing news documentary describing actions of spy
  298. agencies, one would have thought that if anyone had studied it intensly, it
  299. would have been the (then) East and West Germans...
  300.  
  301. Danny  <dburstein@mcimail.com> <----direct e-mail address
  302.  
  303. (A quick note to our younger crowd: The television show in question was "Get
  304. Smart," which was kind of a spoof on the entire spy genre.  It is currently in
  305. syndication throughout the United States, and quite a few other countries as
  306. well).
  307.  
  308. ------------------------------
  309.  
  310. Date: Tue, 29 Dec 92 16:56:45 EDT
  311. From: Jerry Leichter <leichter@lrw.com>
  312. Subject: Latest (?) credit card scams
  313.  
  314. As I was paying for some magazines at a local bookstore today, I happened to
  315. notice two interesting bulletins to store owners - passed on to the people
  316. minding the cash registers - about the latest in credit card fraud.  There
  317. are two closely related frauds involved:
  318.  
  319.     1.  Credit cards with their magnetic stripes re-recorded with a
  320.     different, but valid, account number.  Since these days
  321.     pretty much the entire system runs on what is read off
  322.     the magnetic stripe, with a complete receipt printed for
  323.     you without a need to emboss anything from the original
  324.     card, this is a great way to charge things to someone else.
  325.  
  326.     Their recommendation:  Cross-check the information embossed on
  327.     the card with the information printed on the receipt.  There's
  328.     a reward offered to anyone who finds a "magnetically forged"
  329.     card this way.  In practice, don't bet the ranch.  It's hard
  330.     enough to find anyone who bothers to check the signature any
  331.     more; how many people will bother to check long strings of
  332.     digits?  It's worth keeping in mind that unless the card IS
  333.     checked, there is no good way to prove, or even reliably
  334.     detect, the fraud later:  The only information in the system
  335.     is what came off the magnetic stripe.  (Well, you do have the
  336.     signature - but do stores even bother to keep all those
  337.     signed, printed receipts?  Finding any particular one would
  338.     be a horrible job.)
  339.  
  340.     2.  Someone has apparently gone into business creating fake credit
  341.     cards with valid (stolen) credit card numbers on them.  They
  342.     are currently easily detectable because they all bear the
  343.     name of some particular non-existent bank.  If the creator
  344.     had thought about this a bit, he would have created fake
  345.     Citibank or AT&T cards - even if it were hard to get them to
  346.     look *exactly* like the real ones, they'd still be much, much
  347.     harder to detect than cards "issued" by a specific "First
  348.     Federal of Oshkosh", which since it doesn't exists has issued
  349.     NO real cards.  (I hope I haven't given anyone a new idea.)
  350.  
  351. The potential losses here are staggering.  I don't know who ends up stuck with
  352. the immediate bill for these losses - certainly not the owner of the valid,
  353. stolen credit card (though proving that a fraud has taken place could be time
  354. consuming and painful), most likely not the retailer (after all, he DID get a
  355. "valid card/good transaction" response from whatever agency he checks with).
  356. There should be some interesting finger-pointing between the issuing banks and
  357. the transaction approving agencies.
  358.  
  359. In the end, of course, we all end up paying.  Check your monthly bills
  360. carefully!
  361.                             -- Jerry
  362.  
  363. ------------------------------
  364.  
  365. Date: Tue, 29 Dec 92 23:49:54 -0800
  366. From: griffith@xcf.Berkeley.EDU (Jim "The Big Dweeb" Griffith)
  367. Subject: Risks of satellite-controlled anti-theft devices
  368.  
  369. Here in the Bay Area, there has been a rash of carjacking crimes.  In San
  370. Francisco alone, there have been around 60 carjackings in the past six months
  371. or so.  Several people have been injured when resisting a carjacker - the
  372. latest being a young man who was shot in the head on Christmas Eve when he
  373. wouldn't give up his car.  The police recommend that drivers should give up
  374. their cars to would-be car-jackers, since a life is more valuable than a car.
  375.  
  376. Naturally, Silicon Valley has been working on the problem, the first
  377. solution being a remote-controlled ignition kill switch, operated from a fob
  378. such as those used with active car alarms.  One of our local stations had a
  379. blurb about the latest innovation, which uses pager technology to allow a
  380. car owner to dial a 1-800 number, triggering a pager-like satellite signal
  381. which causes a particular car to kill its ignition.  This way, car owners
  382. can calmly let a carjacker escape with the vehicle, then walk to the nearest
  383. telephone and stop the car in its tracks.
  384.  
  385.  
  386. I thought this was a rather clever use of technology, so I gleefully told one
  387. of my house-mates about it.  His reaction was "gee Jim, now I can hassle you
  388. without ever leaving the house".  This kind of stopped me in my tracks, and
  389. after having thought about it a bit, a number of risks seem evident.
  390. Basically, any kind of "wrong number" risk can potentially create a serious
  391. traffic hazard, as well as resulting in personal annoyance (depending on the
  392. mechanism used to re-allow ignition - especially when the user doesn't have a
  393. car-phone).  You've then got yet another number that you must guard as closely
  394. as an ATM code, but which contains significantly more digits to remember (the
  395. 1-800 number plus a password-like code), and keeping track of that while
  396. keeping it away from others is hard.  Plus, a single fault at a pager company
  397. can cause large-scale regional traffic disruptions (if the device becomes
  398. popular, which it probably will).
  399.                                  Jim
  400.  
  401. ------------------------------
  402.  
  403. Date: Wed, 30 Dec 1992 17:51:47 EST
  404. From: Marc Rotenberg <Marc_Rotenberg@washofc.cpsr.org>
  405. Subject: OECD Security Guidelines
  406.  
  407.         The Organization for Economic Cooperation and Development (OECD) has
  408. adopted international Guidelines for the Security of Information Systems.  The
  409. Guidelines are intended to raise awareness of the risks in the use of
  410. information systems and to establish a policy framework to address public
  411. concerns.
  412.  
  413.        The OECD Security Guidelines should be of special interest to RISKS
  414. readers.  They are similar in form to the 1980 OECD Privacy Guidelines and
  415. will probably have a substantial impact on security policy.
  416.  
  417.       Of course, there are lots of issues left open by the Guidelines,
  418. including the relationship between privacy and security.  But the principles
  419. offer a good starting point for public discussion on security and
  420. risks-related issues.
  421.  
  422.         A copy of the press release and an excerpt from the Guidelines
  423. follows.  For additional information or for a copy of the Guidelines, contact
  424. Ms. Deborah Hurley, OECD, 2, rue Andre-Pascal, 75775 Paris Cedex 16, France
  425. 33-1-45-24-93-71 (tel) 33-1-45-24-93-32 (fax).
  426.  
  427. Marc Rotenberg, Director, CPSR Washington office and Member, OECD Expert
  428. Group on Information System Security           rotenberg@washoc.cpsr.org
  429.  
  430. =============================================================
  431.  
  432.          OECD ADOPTS GUIDELINES FOR THE SECURITY OF INFORMATION SYSTEMS
  433.  
  434.         The 24 OECD Member countries on 26th November 1992 adopted Guidelines
  435. for the Security of Information Systems, culminating almost two years' work by
  436. an OECD expert group composed of governmental delegates, scholars in the
  437. fields of law, mathematics and computer science, and representatives of the
  438. private sector, including computer and communication goods and services
  439. providers and users.
  440.  
  441.         The term information systems includes computers, communication
  442. facilities, computer and communication networks and the information that they
  443. process.  These systems play an increasingly significant and pervasive role in
  444. a multitude of activities, including national economies, international trade,
  445. government and business operation, health care, energy, transport,
  446. communications and education.
  447.  
  448.         Security of information systems means the protection of the
  449. availability, integrity, and confidentiality of information systems.  It is an
  450. international issue because information systems frequently cross national
  451. boundaries.
  452.  
  453.         While growing use of information systems has generated many benefits,
  454. it has also shown up a widening gap between the need to protect systems and
  455. the degree of protection currently in place.  Society has become very
  456. dependent on technologies that are not yet sufficiently dependable.  All
  457. individuals and organizations have a need for proper information system
  458. operations (e.g. in hospitals, air traffic control and nuclear power plants).
  459.  
  460.         Users must have confidence that information systems will be available
  461. and operate as expected without unanticipated failures or problems.
  462. Otherwise, the systems and their underlying technologies may not be used to
  463. their full potential and further growth and innovation may be prohibited.
  464.  
  465.         The Guidelines for the Security of Information Systems will provide
  466. the required foundation on which to construct a framework for security of
  467. information systems.  They are addressed to the public and private sectors and
  468. apply to all information systems.  The framework will include policies, laws,
  469. codes of conduct, technical measures, management and user practices, ad public
  470. education and awareness activities at both national and international levels.
  471.  
  472.         Several OECD Member countries have been forerunners in the field of
  473. security of information systems.  Certain laws and organizational and
  474. technical rules are already in place.  Most other countries are much farther
  475. behind in their efforts.  The Guidelines will play a normative role and assist
  476. governments and the private sector in meeting the challenges of these
  477. worldwide systems.  The Guidelines bring guidance and a real value-added to
  478. work in this area, from a national and international perspective.
  479.  
  480.  
  481. PRINCIPLES
  482.  
  483. 1. Accountability Principle
  484.  
  485.         The responsibilities and accountability of owners, providers and users
  486. of information systems and other parties concerned with the security of
  487. information systems should be explicit.
  488.  
  489. 2.  Awareness Principle
  490.  
  491.         In order to foster confidence in information systems, owners,
  492. providers and users of information systems and other parties should readily be
  493. able, consistent with maintaining security, to gain appropriate knowledge of
  494. and be informed about the existence and general extent of measures, practices
  495. and procedures for the security of information systems.
  496.  
  497. 3. Ethics Principle
  498.  
  499.         Information systems and the security of information systems should be
  500. provided and used in such a manner that the rights and legitimate interests of
  501. others are respected.
  502.  
  503. 4. Multidisciplinary Principle
  504.  
  505.         Measures practices and procedures for the security of information
  506. systems should take into account of and address all relevant consideration and
  507. viewpoints, including technical, administrative, organizational, operational,
  508. commercial, educational and legal.
  509.  
  510. 5.  Proportionality Principle
  511.  
  512.         Security levels, costs, measures, practices and procedures should be
  513. appropriate and proportionate to the value of and degree of reliance on the
  514. information systems and to the severity, probability and extent of potential
  515. harm, as the requirements for security vary depending upon the particular
  516. information systems.
  517.  
  518. 6. Integration Principle
  519.  
  520.         Measures, practices and procedures for the security of information
  521. systems should be co-ordinated and integrated with each other and with other
  522. measures, practices and procedures of the organization so as to create a
  523. coherent system of security.
  524.  
  525. 7. Timeliness Principle
  526.  
  527.         Public and private parties, at both national and international
  528. levels, should act in a timely co-ordinated manner to prevent and to respond
  529. to breaches of information systems.
  530.  
  531. 8.  Reassessment Principle
  532.  
  533.         The security information systems should be reassessed periodically,
  534. as information systems and the requirements for their security vary over time.
  535.  
  536. 9. Democracy Principle
  537.  
  538.         The security of information systems should be compatible with the
  539. legitimate use and flow of data ad information in a democratic society.
  540.  
  541. [Source: OECD Guidelines for the Security of Information Systems (1992)]
  542.  
  543. ------------------------------
  544.  
  545. End of RISKS-FORUM Digest 14.20
  546. ************************
  547.